IBIS Macromodel Task Group Meeting date: 04 August 2020 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Todd Bermensolo * Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Randy to submit the Component_Name and Signal_Name BIRD draft to the Open Forum as an official BIRD. - Done. Submitted as BIRD207. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 28 meeting. Walter moved to approve the minutes. Michael seconded the motion. There were no objections. ------------- New Discussion: DDR5 DQ Write Protocol: Walter briefly reviewed his presentation "DDR5_DQ_Write_Protocol (BIRD147/201)" from last week. (see last week's minutes for the overview discussion) Walter noted that he had proposed two different protocols, a JEDEC protocol that exchanges actual register settings, and a Generic protocol some people might want to use for various reasons such as developing something before a JEDEC standard was released. Walter reiterated that discussions about the eye metrics to be returned by the Rx would likely take time. He noted that the Rx IR is processed by the EDA tool normally, and the EDA tool can convert it to a pulse response and generate eye width, height, area, COM (essentially SNR). He said the Rx would generate these and return them to the Tx in the proposed protocol. He noted that the Rx could return the IR to the Tx, as it typically returns it to the EDA tool, but for this protocol he is proposing that it return the eye metrics. This is more like the way the actual hardware works. Ambrish asked if the Rx could choose to return nothing at all. Walter said the Rx has to return the metrics for these DDR5 DQ Write protocols. He said that DDR5 memory (Rx) is told what to do by the Controller (Tx). All the intelligence is in the Tx, and the Rx must return the eye quality information so the optimization algorithm in the Tx can make use of it. He said this was the antithesis of other standards like 802.x, where the Rx had the smarts and controlled the optimization. Walter reviewed the MATLAB function optPulseMetrics(), which he had developed to generate the same metrics used in these protocols. The function takes an IR as an input. Walter noted that the source code is available to anyone with MATLAB, and that they would be putting the algorithm in the public domain. Arpad asked which toolbox contained the function. Walter said it is part of the SERDES toolbox, and that he would work to get it publicly available quickly. Walter shared the MATLAB code itself and reviewed it. The function takes an IR as in input and manipulates it such that the various metrics can be generated. It provides the capability to automatically fall back to the first BER for which the eye is not closed (eye area > 0). Walter returned to the last slide of his presentation. He said it will be up to IBIS to decide how to handle the protocol proposal. He will work to get agreement on the details in ATM, and he will publish the protocol. Then IBIS can decide if it wants to approve it and how the process would work (the process for approving protocols is left unspecified by BIRD147). Randy asked if there are protocols for other standards that have been released. Walter said he was not aware of any. Ambrish said they had developed some with IP vendors, and had published a protocol at DesignCon one year, but none of them were really in the public domain. Randy asked if Ambrish would want any of them to be public or if they wanted to keep them private. Ambrish said he wasn't sure whether they wanted them private, or if it was just been too much work to take them public without a specified process. Randy said he wanted to find out how much interest there would be if IBIS created a process for approving these protocols. Ambrish took an AR to find out if they would have any interest in taking their protocols public. Randy asked for clarification on slides 3, 4, 5 when they said the Tx sends "tap indices" to the Rx. Walter said that he meant the Tx sends the Rx the actual settings for the tap registers. Given this, slide 5 means (from last week's minutes, with one addition to the JEDEC protocol VrefDQ item suggested by Randy): - What the Rx tells the Tx each iteration: - JEDEC protocol - Return the BER used - Return the gain value corresponding to the register setting the Tx requested - Return the VrefDQ value corresponding to the register setting the Tx requested - Return the DFE indices and the DFE coefficients used - Must return the metrics - Generic protocol - Return the BER used - Return the gain register setting that gives the gain closest to that requested - Return the gain itself - Return the VrefDQ register setting that gives the VrefDQ closest to that requested - Return the VrefDQ value - Return the requested DFE indices (if they were supported) - Return the DFE coefficients - Return the same metrics Ambrish asked if using an increment/decrement approach to adjusting the taps would be easier to communicate. Walter noted that in the JEDEC DDR5 standard the Tx is explicitly setting register values in the Rx. With JEDEC DDR5 it's cast in stone, and the Tx has all the smarts. With things like 802.3.xx, the options aren't so tightly defined, and you need a handshake back and forth because the capabilities of devices may differ. There it makes sense to have an increment/decrement approach, but for DDR5, DQ writes are much more constrained. Randy asked if, as part of the definition, the protocol would define values according to the actual JEDEC DDR5 specification. Walter said now that we have a JEDEC DDR5 specification, the protocol description will say, "for tap 1 it's 0-15... etc., according to the JEDEC DDR5" (for example). He noted that no one will read this, it's not like an AMI file documenting what that user/tool should know. Arpad asked about the logistics of the process of creating this protocol. Bob said the process remains to be seen. Walter said he would start by writing it up and reviewing it with ATM. Randy suggested we might create a template for protocol creation similar to the BIRD template. Arpad asked if the process would be handled in ATM or the Open Forum or some other group. Walter said he would have something ready to review at ATM in the near future. Randy said he would like to get some feedback from controller vendors to confirm that the proposed eye metrics satisfy their needs. Walter said he had some exposure to both controller and memory vendor requirements, but he would like to get feedback from other vendors. Arpad suggested Walter publicize his protocol on the SIlist as well. Walter said he planned to present the protocol at the next Open Forum meeting, and he would send it to SIlist after the presentation. Support PI modeling/simulation in IBIS: Zhiping reported that he hadn't received any feedback or questions based on his presentation at a previous meeting. He said he was focusing his attention on the upcoming IBIS Summit in conjunction with the IEEE EMC SI+PI symposium. IEEE EMC SI+PI is a virtual conference running throughout the month of August. The IBIS Summit is on August 28th from 1 to 5 PM CST. Randy asked if Zhiping might lead a question/answer session to help IBIS members interact with IEEE members. Zhiping said he had recently reached out to the IEEE EMC Chair to see if he could present an introductory overview of IEEE EMC and perhaps talk about ways IBIS and IEEE EMC could collaborate. Randy and Bob said this would be a good presentation for the summit. BIRD181.2: Bob briefly reviewed the purpose of the BIRD and where it is currently hung up. The BIRD is changing some of the notation used in the specification to go to a more precise, SPICE-like terminology. For the Pullup, Pulldown, GND Clamp, and POWER Clamp tables, it will use syntax such as: Vtable = V(Pullup_ref, Buffer_I/O) Bob said one area that is slowing down the effort is the Notes on Data Derivation section. He said the change would make it more complicated to read at first glance, but it would more precisely define the intended ranges in terms of the lowest and highest rails. For example, it shows the recommended lower limit of the Pulldown table extending to -V(Pullup_ref, Pulldown_ref). Arpad asked why have the "-" sign and asked if swapping the order of the two nodes would be easier. Randy said the notation Bob showed made it more obvious the value was negative. Radek noted that what was shown for the upper limit of the range V(2*Pullup_ref, Pulldown_ref) could not be correct, because the 2* was multiplying a node name. Bob agreed it needed more review, and said it was probably 2*V(Pullup_ref, Pulldown_ref). Arpad asked if the changes affected other areas. Bob said they would probably affect the Composite Current and gate modulation effect sections as well. Bob noted, as a helpful pointer to model makers, that it's okay for tables to extend beyond the ranges suggested in the Notes on Data Derivation. In fact, he said he would recommend it as a way to ensure you don't get unintended extrapolation results from tools. - Randy: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Ambrish to find out whether his team would have any interest in taking some of their BCI protocols public if there were a process to do so. ------------- Next meeting: 11 August 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives